prusalink: complete API client implementation - #13

@copilot You are a senior full-stack engineer with expertise in:

• HTTP API client implementation
• TypeScript/JavaScript or C# (choose the language of the existing partial code)
• OpenAPI / REST API patterns
• Clean, minimal, non-breaking code

Context:

• The project uses the PrusaLink API spec from: https://github.com/prusa3d/Prusa-Link-Web/tree/master/spec
• The API defines endpoints for printer status, files, jobs, storage, etc.
• A partial PrusaLink connection implementation already exists in the codebase.
• Your task is to finish and stabilize this API connection implementation.
• Do NOT add unrelated features.

Goals (in order):

1. Complete the PrusaLink API client

   • Ensure all relevant endpoints in the spec (e.g., version/info, printer status, job status, upload/download, storage listing) are implemented.
   • Respect the OpenAPI structure (base URL, versioning, path patterns).

2. Properly handle authentication

   • API keys or credentials from config should be used correctly.
   • Implement token storage and renewal if needed per the spec.
   • Use appropriate headers (Authorization, Content-Type, Accept).

3. Error handling & stability

   • Provide consistent error messages
   • Retry common transient errors (timeouts, network drop)

4. Add types / interfaces

   • Use the OpenAPI definitions to define typed responses
   • Ensure null safety where applicable

5. Write minimal tests

   • For each major endpoint (e.g., status, printer info, job list)
   • Use mocks or stubbed API responses

6. Do NOT change existing behavior

   • Avoid refactoring unrelated code
   • Avoid UI changes
   • Only adjust code to finish missing logic and fix obvious mistakes

7. Produce a tidy PR

   • Title: prusalink: complete API client implementation
   • PR description should include:
     • What was implemented
     • What endpoints are now fully supported
     • What tests were added
     • Any assumptions made about authentication or API behavior
   • Ensure the build passes with no warnings from these changes

Constraints:

• Use the API spec under spec/ as the source of truth
• Do not invent new endpoints not present in the spec
• Preserve existing coding patterns
• Keep changes minimal and reviewable

Deliverables:

• Fully working API client code
• Types/interfaces matching the spec
• Minimal coverage tests
• A clean, self-contained pull request

Proceed methodically: analyze the partial code first, then implement missing endpoints, then add error handling and tests.

@copilot You are a senior full-stack engineer with expertise in:

• HTTP API client implementation
• TypeScript/JavaScript or C# (choose the language of the existing partial code)...

Implemented the PrusaLink client per the published spec: added version/info/status/storage/files support with digest/basic auth configuration, light retries, and typed DTOs; unsupported printer-control commands now return explicit NotSupported messages. Added xUnit tests covering connect/status/file listing with a stubbed handler. Changes in 917d32f.

@copilot now same deal for moonraker: https://moonraker.readthedocs.io/en/latest/external_api/introduction/

@copilot now same deal for moonraker: https://moonraker.readthedocs.io/en/latest/external_api/introduction/

Added Moonraker client coverage: endpoints for info/status/files, gcode-backed controls (temp, moves, speeds), print start, and retries/auth handling, plus xUnit tests with stubbed handler. Changes in 1bb33f0.

@copilot you didnt add the test project to the workflows so that there is a test run

@copilot you didnt add the test project to the workflows so that there is a test run

Added unit test execution to CI (dotnet test MakerPrompt.Tests/MakerPrompt.Tests.csproj) in build.yml so new tests run in the workflow. Changes in 658bf08.